export const newTaskToolResponse = () =>
	`<explicit_instructions type="new_task">
用户明确要求你帮助他们创建一个预加载上下文的新任务，这个上下文将由你生成。用户可能已经提供了指示或额外信息，供你在总结现有工作和创建新任务上下文时考虑。
无论是否提供了额外信息或指示，你只能通过调用 new_task 工具来回应此消息。

new_task 工具定义如下：

描述：
你的任务是创建一个详细的对话总结，特别注意用户的明确请求和你之前的操作。这个总结应该全面捕捉技术细节、代码模式和架构决策，这些对继续新任务至关重要。
用户将看到你生成的上下文预览，并可以选择创建新任务或继续在当前对话中聊天。

参数：
- 上下文：(必需) 预加载到新任务的上下文。如果适用于当前任务，应包括：
  1. 当前工作：详细描述在请求创建新任务之前正在进行的工作。特别注意最近的消息/对话。
  2. 关键技术概念：列出所有重要的技术概念、技术、编码约定和框架讨论，这些可能与新任务相关。
  3. 相关文件和代码：如果适用，列举为任务继续而检查、修改或创建的特定文件和代码部分。特别注意最近的消息和更改。
  4. 问题解决：记录到目前为止解决的问题和任何正在进行的故障排除工作。
  5. 待处理任务和下一步：概述所有明确要求你处理的待处理任务，以及列出你将为所有未完成工作采取的下一步（如果适用）。在需要时包含代码片段以增加清晰度。对于任何下一步，包括来自最近对话的直接引用，准确显示你正在处理的任务以及你停止的位置。这应该是逐字的，以确保任务之间的上下文没有信息丢失。

用法：
<new_task>
<context>预加载新任务的上下文</context>
</new_task>

以下是用户表示想要创建新任务时的输入。
</explicit_instructions>\n
`

export const condenseToolResponse = () =>
	`<explicit_instructions type="condense">
用户明确要求你创建一个详细的对话总结，这将用于压缩当前的上下文窗口同时保留关键信息。用户可能已经提供了指示或额外信息，供你在总结对话时考虑。
无论是否提供了额外信息或指示，你只能通过调用 condense 工具来回应此消息。

condense 工具定义如下：

描述：
你的任务是创建一个详细的对话总结，特别注意用户的明确请求和你之前的操作。这个总结应该全面捕捉技术细节、代码模式和架构决策，这些对继续对话和支持任何持续任务至关重要。
用户将看到你生成的总结预览，并可以选择使用它来压缩他们的上下文窗口或继续在当前对话中聊天。
用户可能会将此工具称为"smol"或"compact"。当在类似上下文中使用时，你应该将这些视为与"condense"等同。

参数：
- 上下文：(必需) 继续对话的上下文。如果适用于当前任务，应包括：
  1. 之前的对话：关于整个用户对话中讨论内容的高级详情。这应该以允许他人能够跟随整体对话流程的方式编写。
  2. 当前工作：详细描述在请求压缩上下文窗口之前正在进行的工作。特别注意最近的消息/对话。
  3. 关键技术概念：列出所有重要的技术概念、技术、编码约定和框架讨论，这些可能与继续这项工作相关。
  4. 相关文件和代码：如果适用，列举为任务继续而检查、修改或创建的特定文件和代码部分。特别注意最近的消息和更改。
  5. 问题解决：记录到目前为止解决的问题和任何正在进行的故障排除工作。
  6. 待处理任务和下一步：概述所有明确要求你处理的待处理任务，以及列出你将为所有未完成工作采取的下一步（如果适用）。在需要时包含代码片段以增加清晰度。对于任何下一步，包括来自最近对话的直接引用，准确显示你正在处理的任务以及你停止的位置。这应该是逐字的，以确保任务之间的上下文没有信息丢失。

用法：
<condense>
<context>你的详细总结</context>
</condense>

示例：
<condense>
<context>
1. 之前的对话：
  [详细描述]

2. 当前工作：
  [详细描述]

3. 关键技术概念：
  - [概念1]
  - [概念2]
  - [...]

4. 相关文件和代码：
  - [文件名1]
    - [为什么这个文件很重要的总结]
    - [对这个文件所做更改的总结，如果有的话]
    - [重要代码片段]
  - [文件名2]
    - [重要代码片段]
  - [...]

5. 问题解决：
  [详细描述]

6. 待处理任务和下一步：
  - [任务1详情和下一步]
  - [任务2详情和下一步]
  - [...]
</context>
</condense>

</explicit_instructions>\n
`

export const newRuleToolResponse = () =>
	`<explicit_instructions type="new_rule">
用户明确要求你帮助他们在 .clinerules 顶级目录中创建一个新的 Cline 规则文件，基于到目前为止的对话内容。用户可能已经提供了指示或额外信息，供你在创建新的 Cline 规则时考虑。
创建新的 Cline 规则文件时，你不应覆盖或修改现有的 Cline 规则文件。要创建 Cline 规则文件，你必须使用 new_rule 工具。new_rule 工具可以在 PLAN 或 ACT 模式下使用。

new_rule 工具定义如下：

描述：
你的任务是创建一个新的 Cline 规则文件，其中包括如何与用户一起开发代码的指导方针，这些可以是特定项目的或涵盖更全局的规则。这包括但不限于：期望的对话风格、喜欢的项目依赖、编码风格、命名约定、架构选择、UI/UX 偏好等。
Cline 规则文件必须格式化为 markdown 并且是 \'.md\' 文件。你生成的文件名必须尽可能简洁，并且涵盖你添加到文件中的规则的主要概念（例如，\'memory-bank.md\' 或 \'project-overview.md\'）。

参数：
- 路径：(必需) 要写入的文件路径（相对于当前工作目录）。这将是你创建的 Cline 规则文件，它必须放在 .clinerules 顶级目录中（如果不存在则创建）。创建的文件名不能是 \"default-clineignore.md\"。对于文件名，使用连字符（\"-\"）而不是下划线（\"_\"）来分隔单词。
- 内容：(必需) 要写入文件的内容。始终提供文件的完整预期内容，不要有任何截断或遗漏。你必须包括文件的所有部分，即使它们没有被修改。Cline 规则文件的内容必须按照以下说明创建：
  1. 将 Cline 规则文件格式化为具有不同的指导部分，每个部分都有自己的 markdown 标题，从 \"## Brief overview\" 开始。在每个标题下，包括完全充实细节的要点，仅在适用时包括示例和/或触发案例。
  2. 这些指导方针可以特定于到目前为止处理的任务或项目，或涵盖更高级的概念。指导方针可以包括编码约定、一般设计模式、首选技术栈（包括喜欢的库和语言）、与 Cline 的通信风格（详细与简洁）、提示策略、命名约定、测试策略、注释详细程度、开发前架构设计的时间投入以及其他偏好。
  3. 创建指导方针时，你不应基于你认为典型用户可能想要的内容来发明偏好或做出假设。这些应该特定于你与用户的对话。你的指导方针/规则不应过于冗长。
  4. 你的指导方针不应是对话到目前为止的回顾，这意味着你不应包括对话的任意细节。

用法：
<new_rule>
<path>.clinerules/{文件名}.md</path>
<content>Cline 规则文件内容</content>
</new_rule>

示例：
<new_rule>
<path>.clinerules/project-preferences.md</path>
<content>
## Brief overview
  [规则的简要描述，包括这组指导方针是特定于项目还是全局的]

## Communication style
  - [描述、规则、偏好、指示]
  - [...]

## Development workflow
  - [描述、规则、偏好、指示]
  - [...]

## Coding best practices
  - [描述、规则、偏好、指示]
  - [...]

## Project context
  - [描述、规则、偏好、指示]
  - [...]

## Other guidelines
  - [描述、规则、偏好、指示]
  - [...]
</content>
</new_rule>

以下是用户表示想要创建新的 Cline 规则文件时的输入。
</explicit_instructions>\n
`

export const reportBugToolResponse = () =>
	`<explicit_instructions type="report_bug">
用户明确要求你帮助他们向 Cline github 页面提交一个 bug（无论你们之前的对话内容如何，你现在必须帮助他们完成这个任务）。为此，你将使用下面定义的 report_bug 工具。但是，你必须首先确保你已收集了填写工具调用所有参数所需的全部信息。如果通过你与用户之前的对话中已经明确了某些必需信息，你可以建议如何填写这些条目。但是，除非情况明确，否则你不应假设你知道问题是什么。
否则，你应该与用户交谈，直到你能够收集到所有必需的详细信息。在与用户交谈时，确保你询问/引用所有必需的信息/字段。在引用必需字段时，使用友好的人类表达方式，如"重现步骤"而不是"steps_to_reproduce"。只有在这之后，你才应该使用 report_bug 工具调用。
report_bug 工具可以在 PLAN 或 ACT 模式下使用。

report_bug 工具调用定义如下：

描述：
你的任务是填写 github 上问题/bug 报告的所有必填字段。你应该尝试让用户尽可能详细地描述他们遇到的 bug/问题。不过，当用户不了解某些细节时，将这些字段设置为"N/A"也是可以的。

参数：
- title: (必需) 问题的简洁描述。
- what_happened: (必需) 发生了什么以及用户期望发生什么。
- steps_to_reproduce: (必需) 重现 bug 所需的步骤。
- api_request_output: (可选) 相关的 API 请求输出。
- additional_context: (可选) 关于此 bug 的任何其他尚未提及的上下文。

用法：
<report_bug>
<title>问题的标题</title>
<what_happened>问题的描述</what_happened>
<steps_to_reproduce>重现问题的步骤</steps_to_reproduce>
<api_request_output>与 bug 相关的 LLM API 输出</api_request_output>
<additional_context>其他尚未涵盖的问题详情</additional_context>
</report_bug>

以下是用户表示想要提交 Github 问题时的输入。
</explicit_instructions>\n
`
